MIZIKOVSKY 25 
Ser. NO. 09/500869 
Filed 2/9/00 



(19) 



(12) 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 




(43) Date ot publication: 

02.02.2000 Bulletin 2000/05 



(11) EP 0 977 452 A2 

EUROPEAN PATENT APPLICATION 

(51) intci7: H04Q 7/38, H04L9/08 



(21) Application number: 99305705.8 

(22) Date of filing: 20.07.1999 



(84) Designated Contracting States: 

AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 
MC NL PT SE 

Designated Extension States: 
AL LT LV MK RO SI 

(30) Priority: 31.07.1998 US 127768 

(71) Applicant: LUCENT TECHNOLOGIES INC. 
Murray Hill, New Jersey 07974-0636 (US) 



(72) Inventor: Patel, Sarvar 

Montvllle, New Jersey 07045 (US) 

(74) Representative: 

Buckley, Christopher Simon Thirsk et al 

Lucent Technologies (UK) Ltd, 

5 Mornington Road 

Woodford Green, Essex 1G8 OTU (GB) 



(54) Method for updating secret shared data in a wireless communication system 



(57) In the method for updating secret shared data 
(SSD) in a wireless comnnunication systenn, a first party 
outputs a first random number as a first challenge 
wherein the first party is one of a network and a mobile. 
A second party generates a second random number in 
response to the first challenge. The second party is the 
mobile if the first party is the network, and the second 
party is the network if the first party is the mobile. The 
second party generates a first challenge response by 
performing a keyed cryptographic function (KCF) on the 
first challenge and the second random number using a 
secondary key which is not the SSD and is derived from 



a root key. The second party then transfers the second 
random number, as a second challenge, and the first 
challenge response to the first party The first party ver- 
ifies the second party based on the first and second 
challenges and the first challenge response, generates 
a second challenge response by performing the KCF on 
the second challenge using the secondary key, and 
transfers the second challenge response to the second 
party. The second party verifies the first party based on 
the second challenge and the second challenge re- 
sponse. Both parties respectively establish the SSD 
based on the first and second challenges. 
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Description 
Related Applications 

[0001] The following applications, filed concurrently 
with the subject application, are related to the subject 
application and are hereby incorporated by reference in 
their entirety: application no. unknown entitled METH- 
OD FOR TWO PARTY AUTHENTICATION AND KEY 
AGREEMENT by the inventor of the subject application; 
application no. unknown entitled METHOD FOR 
TRANSFERRING SENSITIVE INFORMATION USING 
INTIALLY UNSECURED COMMUNICATION by the in- 
ventor of the subject application; application no. un- 
known entitled METHOD FOR SECURING OVER-THE- 
AIR COMMUNICATION IN A WIRELESS SYSTEM by 
the inventor of the subject application; and application 
no. unknown entitled METHOD FOR ESTABLISHING A 
KEY USING OVER-THE-AIR COMMUNICATION AND 
PASSWORD PROTOCOL AND PASSWORD PROTO- 
COL by the inventor of the subject application and Adam 
Berenzweig. 

Field Of The Invention 

[0002] The present invention relates to a method for 
updating secret shared data in a wireless communica- 
tion system. 

Description Of Related Art 

[0003] The U.S. currently utilizes three major wireless 
systems, with differing standards. The first system is a 
time division multiple access system (TDMA) and is gov- 
erned by IS-136, the second system is a code division 
multiple access (CDMA) system governed by IS-95, and 
the third is the Advanced Mobile Phone System 
(AMPS). All three communication systems use the IS- 
41 standard for intersystem messaging, which defines 
the authentication procedure when updating the secret 
shared data. 

[0004] Fig. 1 illustrates a wireless system including an 
authentication center (AC) and a home location register 
(HLR) 10, a visiting location register (VLR) 15, and a 
mobile 20. While more than one HLR may be associated 
with an AC, currently a one-to-one correspondence ex- 
ists. Consequently, Fig. 1 illustrates the HLR and AC as 
a single entity, even though they are separate. Further- 
more, for simplicity, the remainder of the specification 
will refer to the HLR and AC jointly as the AC/HLR. Also, 
the VLR sends information to one of a plurality of mobile 
switching centers (MSCs) associated therewith, and 
each MSC sends the information to one of a plurality of 
base stations (BSs) for transmission to the mobile. For 
simplicity, the VLR, MSCs and BSs will be referred to 
and illustrated as a VLR. Collectively, the ACs, HLRs, 
VLRs, MSCs, and BSs operated by a network provider 
are referred to as a network. 



[0005] A root key. known as the A-key, is stored only 
in the AC/HLR 1 0 and the mobile 20. There is a second- 
ary key. known as Shared Secret Data SSD. which is 
sent to the VLR 15 as the mobile roams (i.e., when the 
5 mobile is outside its home coverage area). SSD is gen- 
erated from the A-key and a random seed RANDSSD 
using a cryptographic algorithm or function. A crypto- 
graphic function is a function which generates an output 
having a predetermined number of bits based on a 
TO range of possible inputs. A keyed cryptographic function 
(KCF) is a type of cryptographic function that operates 
based on a key; for instance, a cryptographic function 
which operates on two or more arguments (i.e., inputs) 
wherein one of the arguments is the key. From the out- 
15 put and knowledge of the KCF in use, the inputs can not 
be determined unless- the key is known. Encryption/de- 
cryption algorithms are types of cryptographic functions. 
So are one-way functions like pseudo random functions 
(PRFs) and message authentication codes (MACs). 
20 The expression KCFsk(Rn') represents the KCF of the 
random number R^' using the session key SK as the 
key. A session key is a key that lasts for a session, and 
a session is a period of time such as the length of a call. 
[0006] In the lS-41 protocol, the cryptographic func- 
2S tion used is CAVE (Cellular Authentication and Voice 
Encryption). When the mobile 20 roams, the VLR 15 in 
that area sends an authentication request to the AC/ 
HLR 10. which responds by sending that mobile's SSD. 
Once the VLR 15 has the SSD, it can authenticate the 
30 mobile20independentlyof the AC/HLR 10. For security 
reasons, the SSD is periodically updated. 
[0007] Fig. 2 illustrates the communication between 
the AC/HLR 10, the VLR 1 5 and the mobile 20 to update 
the SSD. As discussed above, the AC/HLR 10 gener- 
is ates a random number seed RANDSSD. and using the 
CAVE algorithm generates a new SSD using the random 
number seed RANDSSD. The SSD is 1 28 bits long. The 
first 64 bits serve as a first SSD, referred to as SSDA, 
and the second 64 bits serve as a second SSD, referred 
40 to as SSDB. As shown in Fig. 2, the AC/HLR 1 0 provides 
the VLR 15 with the new SSD and the RANDSSD. The 
VLR 15 then sends the RANDSSD to the mobile 20 
along with a session request SR. The session request 
SR instructs the mobile 20 to perform the SSD update 
• -^5- protocol which is described in detail below. In response 
to receipt of the RANDSSD and the session request SR, 
the mobile 20 uses the CAVE algorithm to generate the 
new SSD using the RANDSSD, and generates a ran- 
dom number RM using a random number generator. 
so The mobile 20 sends the random number R(y, to the VLR 
15. The mobile 20 also performs the CAVE algorithm on 
the random number R^ using the new SSDA as the key. 
This calculation is represented by CAVEssdaC^m)- 
[0008] One of the VLR 15 and the AC/HLR 10, also 
55 calculates CAVEqsdaC^m )- sends the result to the 
mobile 20. The mobile 20 authenticates the network if 
CAVEssdaC^m )• which it calculated, matches that re- 
ceived from the network. 
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[0009] Next, and usually after receiving a signal from 
the mobile 20 indicating verification, the VLR 15 gener- 
ates a random number R^, and sends the random 
number to the mobile 20. Meanwhile, the VLR cal- 
culates CAVEssda(Rn)- Upon receipt of R^. the mobile 
20 calculates CAVEssDA(f^N)' ^^^i sends the result to 
the VLR 15. The VLR 15 authenticates the mobile jf 
CAVEssoa(Rn). which it calculated, matches that re- 
ceived from the mobile 20. The random numbers and 
Rn are referred to as challenges, while CAVEssdaC^m ) 
and CAVEssDA(f^N) referred to as challenge re- 
sponses. Once the authentication is complete, the mo- 
bile 20 and the network generate session keys using 
SSDB. 

[0010] In this protocol, the SSD is itself used to an- 
swerthe challenges from the mobile 20 and the network. 
This allows an attack when an old RANDSSD and SSD 
pair are revealed. Knowing this pair is enough to query 
the mobile 20, and answer its challenge. Thus an attack- 
er can issue an SSD update to the mobile 20, and an- 
swer the challenge from the mobile. Once the revealed 
SSD is accepted, and despite a secure session key 
agreement protocol (i.e., a protocol on communication 
between a mobile and a network to establish a session 
key), the attacker can impersonate the network and 
place a call to the mobile 20 under fraudulent identities. 
For example, the impersonator can insert his own caller 
id or name and pretend to be someone else. The attack- 
er can pretend to be a credit card company, and ask to 
verify card number and pin. Or even use the telephone 
company name in the caller name field and ask to verify 
calling card numbers, etc. 



Summary Of The Invention Error! Bookmark not 
defined 



challenge response. Based on the second challenge 
and receipt of the second challenge response, the sec- 
ond party verifies the first party. Using the first and sec- 
ond challenges, the secret shared data is generated by 
5 both parties. In this manner, a different key, the second- 
ary key. from the secret shared data key is used in an- 
swering challenges. 
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[0011] In the method for updating secret shared data 
(SSD) in a wireless communication system according to 
the present invention, a first party issues a random 
number as a first challenge and a second party re- 
sponds with a first challenge response. The first party is 
either the network or a mobile. The second party is the 
mobile when the first party is the network, and the sec- 
ond party is the network when the first party is the mo- 
bile. The second party generates a second random 
number. Then, the first challenge response is generated 
by performing a keyed cryptographic function (KCF) on 
the first challenge and the second random number using 
a secondary key. The secondary key is derived by both 
the first and second party from a root key, and is not the 
secret shared data. The second party generates the 
second random number upon receipt of the first chal- 
lenge, and uses the second random number as a sec- 
ond challenge. The first party verifies the second party 
based on the first challenge and receipt of the second 
challenge and the first challenge response. After verifi- 
cation, the first party performs the KCF on the second 
challenge using the secondary key to generate a second 



Brief Description Of The Drawings 



[0012] The present invention will become more fully 
understood from the detailed description given below 
and the accompanying drawings which are given by way 
of illustration only, wherein like reference numerals des- 
75 ignate corresponding parts in the various drawings, and 
wherein: 

Fig. 1 is a block diagram illustrating the basic com- 
ponents of a wireless system 
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Fig. 2 illustrates the communication between the 
authentication center/home location register, visit- 
ing location register, and the mobile to update the 
secret shared data according to the IS-41 standard; 

Fig. 3 illustrates the communication between the 
authentication center/home location register, visit- 
ing location register, and the mobile to update the 
secret shared data according to one embodiment 
of the present invention; 

Fig. 4 illustrates the communication between the 
authentication center/home location register, visit- 
ing location register, and the mobile to update the 
secret shared data according to another embodi- 
ment of the present invention; and 

Fig. 5 illustrates the communication between the 
authentication center/home location register, visit- 
ing location register, and the mobile to update the 
secret shared data according to a further embodi- 
ment of the present invention. 

Detailed Description Of The Preferred Embodiments 



[001 3] The method or protocol for updating the secret 
shared data according to the present invention is em- 
ployed by the same wireless system shown in Fig. 1 . In 
the method according to the present invention, however, 

so the AC/HLR 1 0 and the mobile 20 also generate another 
key, referred to as the M-key, based on the root or A- 
key. For example, the M-key is generated by applying a 
pSGudo random function (PRF) indexed by the A-key on 
a known value. A practical PRF is the well-known Data 

55 Encryption Standard-Cipher Block Chaining (DES- 
CBC) from the NIST (National Institute of Standards) . 
In a preferred embodiment. DES-CBC, indexed by a 
64-bit A-key on a value known to both the network and 
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the mobile 20, produces a 64-bit M-key. 
[0014] Fig. 3 illustrates the communication between 
the AC/HLR 1 0, the VLR 1 5. and the mobile 20 to update 
the secret shared data according to one embodiment of 
the present invention. As shown, the VLR 1 5 merely acts 
as a conduit lor communication between the AC/HLR 
10 and the mobile 20. More specifically, the authentica- 
tion protocol according to the present invention is per- 
formed between the AC and the mobile 20. 
[001 5] To update the SSD. the AC/HLR 1 0 generates 
a random number f^j^ using a random number genera- 
tor, and sends the random number R^ along with a ses- 
sion request SR to the mobile 20. The session request 
SR instructs the mobile 20 to perform the update SSD 
protocol. In response tothe session request SR, the mo- 
bile 20 generates a random number R^^ using a random 
number generator, and performs a keyed cryptographic 
algorithm or function (KCF) on the random numbers R^j 
and Rm, Type data, and id data 0 using the M-key as the 
key. This calculation is represented as KCpM-Key C^VP^' 
0, R^, FIn)-/ Preferably, the KCF is a keyed message au- 
thentication code such as HMAC, but could be a FRF 
such as DES-CBC. The Type data represents the type 
of protocol being performed; namely, the SSD update 
protocol. Other protocol types includes call origination, 
call termination, and mobile registration. The id data 0 
indicates that the communication issued from the mo- 
bile: id data 1 , by contrast, indicates that the communi- 
cation is from the network. 

[0016] Because the AC/HLR 10 initiated the SSD up- 
date protocol with the session request SR, the AC/HLR 
10 knows the Type data, and because communication 
from mobiles include the same id data of 0, this value is 
known as well by the AC/HRL 10. Accordingly, upon re- 
ceipt of Rm, the AC/HLR 10 calculates KCF^-Key (Type. 
0, Rm, Rn)- The AC/HLR 10 then verifies whether the 
calculated version of KCFM.Key(Type, 0. Rm. Rn) match- 
es the version received from the mobile 20. If a match 
is found, the AC/HLR 10 authenticates the mobile 20. 
Next, the AC/HLR 10 calculates KCF^^.Key(Type. 1, 
Rm ), where 1 is the id data of the network, and sends 
the calculated result to the mobile 20. 
[0017] The mobile 20 knows the Type data from the 
session request SR, and knows that communication 
from the network includes id data of 1 . Accordingly, the 
mobile 20 calculates KCF^.Key (Type, 1. Rm )- The mo- 
bile 20 then verifies whether the calculated version of 
KCFM.Key(Type, 1 , Rm) matches the version received 
from the AC/HLR 1 0. If a match is found, the mobile 20 
authenticates the network. 

[001 8] After authenticating the network, the mobile 20 
and the AC/HLR 10 both have random numbers R^ and 
R^fl. Both the mobile 20 and AC/HLR 10 generate the 
SSD as PRF^-Key (R,^ ,Rn) ; wherein the PRF is pref- 
erably DES-CBC. 

[0019] As an alternative, instead of generating and 
sending a unique random number RN to each mobile 
with the session request SR, the AC/HLR 1 0 generates 



a global random number R^; namely, the same random 
number for all the mobiles. This alternative embodiment 
applies, however, when the anticipated response time 
for the mobile, as monitored by the network, is kept the 
5 same as when a unique random number is sent. If 
longer response durations are desired when using the 
global random number R^, then, preferably, the embod- 
iment discussed below with respect to Fig. 5 should be 
used. 

10 [0020] The IS41 protocol allows for SSD update via 
sharing with the VLR 1 5. The AC/HLR 1 0 sends the SSD 
to the VLR 15, and the VLR 15 challenges the mobile 
20 and answers the challenges from the mobile 20. In 
the protocol according to the present invention the SSD 
15 is not used to answer challenges, and thus the network 
impersonation problem discussed with respect to 1841 
is not possible. Furthermore, even if the M-key is re- 
vealed to an attacker, there is no direct way to obtain 
the A-key therefrom because a one-way function was 
20 used to generate the M-key. Even if the attacker knows 
an old Rm Rn and SSD, there is no way to use that in- 
formation and the M-key information to get either the 
network or the mobile 20 to accept the revealed SSD 
because one of the sides in the communication will be 
25 using its on challenge, which with very high probability 
will be different than the old ones. Further, the new SSD 
will be generated by the PRF of the new challenge using 
the A-key, and the attacker does not know the A-key. 
[0021] The SSD update protocol discussed above 
30 with respect to Fig. 3, however, allows a cryptanalyst to 
mount a chosen plaintext attack against the M-key. 
Namely, a cryptanalyst can impersonate the network 
and query the mobile 20 by sending various challenges 
Rn. By collecting the responses, the cryptanalyst might 
35 be able to recover the M-key. Fig. 4 illustrates the com- 
munication between the AC/HLR 10, the VLR 15, and 
the mobile 20 to update the secret shared data accord- 
ing to another embodiment of the present invention, 
which overcomes the problem noted above with respect 
40 to Fig. 3. As shown, in this embodiment, the VLR 1 5 also 
acts as a conduit for communication between the AC/ 
HLR 1 0 and the mobile 20. More specifically, the authen- 
tication protocol according to the present invention is 
performed between the AC and the mobile 20. 
■45' [0022] To update the SSD, the AC/HLR 10 generates 
a session request SR to initiate the SSD update. In re- 
sponse, the mobile 20 generates a random number R,^, 
and sends the random number RM to the AC/HLR 10. 
The AC/HLR 10 generates the random number Rfg. and 
50 calculates the KCF^;|.Key(Type. 1, R^. ^n). where 1 is 
the network id data. The AC/HLR 10 sends both the ran- 
dom number RN and the KCF^-KeyCType: 1 . Rm> ^n) to 
the mobile 20. 

[0023] Upon receipt of the random number RN, the 
55 mobile 20 calculates KCF|v,.Key(Type. L Rm' ^n)- The 
mobile 20 then verifies whether the calculated version 
of KCFf^.Key(Type, 1, Rm. ^n) matches the version re- 
ceived from the AC/HLR 10. If a match is found, the mo- 
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bile 20 authenticates the network. 
[0024] Next, the mobile 20 calculates KCFM-KeyC'VPe. 
0, Rn). where 0 Is the id data of the mobile 20. and sends 
the calculated result to the AC/HLR 10. TheAC/HLR 10. 
meanwhile, calculates KCFp^.Key(Type. 0, R^,) as welL 
The AC/H LR 1 0 then verifies whether the calculated ver- 
sion of KCFM.Key(Type, 0, Rn) matches the version re- 
ceived from the mobile 20. if a match is found, the AC/ 
HLR 10 authenticates the mobile 20. 
[0025] Afterauthenticating the network, the mobile 20 
and the AC/HLR 10 both have random numbers R^, and 
R,^. Both the mobile 20 and AC/HLR 10 generate the 
SSD as PRFA-Key(RM. Rn); wherein the PRF is prefer- 
ably DES-CBC. 

[0026] In the embodiment of Fig. 4, an attacker can 
not query mobiles with a chosen text and expect a re- 
sponse. The attacker can only collect known texts from 
previous sessions, because the initiator of the update, 
the network, does not send the first challenge in the 
clear. 

[0027] Fig. 5 illustrates the communication between 
the AC/HLR 1 0, the VLR 1 5, and the mobile 20 to update 
the secret shared data according to a further embodi- 
ment of the present invention. As shown, the VLR 15 
acts as a conduit for communication between the AC/ 
HLR 1 0 and the mobile 20.. More specifically, the authen- 
tication protocol according to the present invention is 
performed between the AC and the mobile 20. 
[0028] To update the SSD. the AC/HLR 10 generates 
and outputs a global random number R^^ along with a 
session request SR to the mobile 20. The session re- 
quest SR instructs the mobile 20 to perform the update 
SSD protocol. In the embodiment ot Fig. 3. the random 
number R^ initially sent by the network to the mobile 20 
was unique to the mobile 20. Different random numbers 
are generated and sent to other mobiles in updating their 
SSDs. In the embodiment of Fig. 5, however, the same 
random number R,s^ is sent by the AC/HLR 20 to all the 
mobiles 20. As discussed above, the embodiment of 
Fig. 5 is preferred over using a global random number 
Rn in the embodiment of Fig. 3 when providing for a 
longer response duration from the mobile 20 is desired. 
[0029] As shown in Fig. 5, in response to the session 
request SR and the random number Rfg sent by the AC/ 
HLR 10, the mobile 20 generates a random number R^. 
generates a count value CT, and calculates KCF^.Key 
(Type, 0, R^. Rn. CT), where 0 is the id data for the mo- 
bile 20. The mobile 20 includes a counter which gener- 
ates the count value CT The mobile 20 increments the 
count value prior to generating the challenge response 
(i.e., KCFM.Key(Type, 0, R„, Rn- CT)) to each SSD up- 
date request. The mobile 20 sends the count value CT, 
random number R^^, and KCFf^.(^gy(Type, 0. R,y,, R^. CT) 
to the network. 

[0030] Upon receipt ot the random number R^^ and 
the count value CT, the AC/HLR 1 0 stores the count val- 
ue CT and determines whether the received count value 
CT exceeds the previously stored count value. If the re- 



ceived count value CT does exceed the previously 
stored count value, then the AC/HLR 10 goes fonward 
with verifying the mobile 20. Namely, based on the re- 
ceived random number R^ and the count value CT. the 

5 AC/HLR 10 calculates KCF^. Key(Type. 0. R^. Rn' CT). 
and determines whether this calculated version match- 
es the version received from the mobile 20. If a match 
is found, the AC/HLR 10 authenticates the mobile 20. If 
the received count value CT does not exceed the pre- 

70 viously stored count value, the mobile 20 is not verified. 
[0031] Once the mobile 20 has been verified, the AC/ 
HLR 10 calculates KCFp^.Key(Type, 1 , Rm ), where 1 is 
the id data for the network, and sends the calculated 
result to the mobile 20. The mobile 20, meanwhile, cal- 

is culates KCFp^. Key(Type, 1 . R^ ) as well. The mobile 20 
then verifies whether the calculated version of KCF^^j.^ey 
(Type, 1 , R|^) matches the version received from the AC/ 
HLR 1 0. If a match is found, the mobile 20 authenticates 
the network. 

20 [0032] After authenticating the network, the mobile 20 
and the AC/HLR 1 0 both have random numbers R^g and 
R^ and the count value CT Both the mobile 20 and AC/ 
HLR 10 generate the SSD as PRFA-KeyC^M '^N' CT); 
wherein the PRF is preferably DES-CBC. 

25 [0033] Because an attacker uses prior challenges and 
challenge responses when mounting an attack as dis- 
cussed above with respect to Fig. 3, such an attack will 
fail if made on the protocol ot Fig. 5. The reason is that 
the attacker will be using a challenge response based 

30 on an old count value. Consequently, the network will 
not verify the attacker, and the attacker can not generate 
the SSD. 

[0034] The invention being thus described, it will be 
obvious that the same may be varied in many ways. 
35 Such variations are not to be regarded as a departure 
from the spirit and scope of the invention, and all such 
modifications are intended to be included within the 
scope of the following claims. 

40 

Claims 

1 . A method for updating secret shared data (SSD) at 
a first party in a wireless communication system, 
. 45 ..-.* cbinprising: 

(a) receiving a random number from a second 
party as a first challenge, said first challenge 
being a global challenge from said second par- 

50 ty; 

(b) generating a second random number in re- 
sponse to said first challenge; 

55 (c) generating a first challenge response by 

performing a keyed cryptographic function 
(KCF) on said first challenge and said second 
random number using a secondary key; 
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(d) transferring said second random number, as 
a second challenge, and said first challenge re- 
sponse to said second party; 

(e) receiving a second challenge response from 
said second party, said second challenge re- 
sponse being a result of performing said KCF 
on said second challenge using said secondary 
key; 

(f) verifying said second party based on said 
second challenge and said second challenge 
response; and 

(g) establishing said SSD based on said first 
and second challenges. 

2. The method of claim 1 . wherein said first party is a 
network and said second party is a mobile. 

3. The method of claim 2, further comprising; 

(h) transferring an update SSD request to said 
mobile; and wherein 

said step (a) receives said first challenge in re- 
sponse to said update SSD request. 

4. The method of claim 1 . wherein said step (c) gen- 
erates said first challenge response by performing 
said KCF on said first challenge, said second chal- 
lenge, and an identifier for said first party using said 
secondary key. 

5. The method of claim 1, wherein said step (c) gen- 
erates said first challenge response by performing 
said KCF on said first challenge, said second chal- 
lenge and type data using said secondary key, said 
type data indicating an update SSD protocol is be- 
ing performed by said first and second parties. 

6. The method of claim 1, wherein said step (c) gen- 
erates said first challenge response by performing 
said KCF on said first challenge, said second chal- 
lenge, an identifier for said first party and type data- 
using said secondary key said type data indicating 
an update SSD protocol is being perfonned by said 
first and second parties. 

7. The method of claim 1 , wherein said first party is a 
mobile and said second party is a network. 



9. 
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15 



sponse by performing said KCF on said first 
challenge, said second challenge, and said 
count value using said secondary key; 

said step (d) transfers said second challenge, 
said first challenge response, and said count 
value from said mobile to said network. 

The method of claim 1 , wherein said secondary key 
is derived from a root key. 
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10. The method of claim 1 , wherein said secondary key 
is not a secret shared data. 

11 . A method for updating secret shared data (SSD) at 
a first party in a wireless communication system, 
comprising: 

(a) globally outputting a random number as a 
first challenge to a second party; 

(b) receiving a second random number, as a 
second challenge, and a first challenge re- 
sponse from said second party, said first chal- 
lenge response being a result of a keyed cryp- 
tographic function (KCF) on said first challenge 
and said second random number using a sec- 
ondary key; 

(c) verifying said second party based on said 
first and second challenges and said first chal- 
lenge response; and 

(d) establishing said SSD based on said first 
and second challenges. 

12. The method of claim 11 , wherein said first party is 
a mobile and said second party is a network. 



40 . 13. The method of claim 12, further comprising: 

(e) receiving an update SSD request from said 
network; and wherein 

45 ' said step (a) outputs said first challenge in re- 

sponse to said update SSD request. 

14. The method of claim 11 , wherein said first party is 
a network and said second party is a mobile. 
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8. The method of claim 7, further comprising: 

(k) incrementing a count value in response to 55 
said first challenge; and wherein 

said step (c) generates said first challenge re- 



15. The method of claim 11 , further comprising: 

(e) generating a second challenge response by 
performing said KCF on said second challenge 
using said secondary key; and 

(h) transferring said second challenge re- 
sponse to said second party. 
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16. The method ot claim 15, wherein said step (e) gen- 
erates said second challenge response by perform- 
ing said KCF on said second challenge and an iden- 
tifier for said first party using said secondary key. 

17. The method of claim 15, wherein said step (e) gen- 
erates said second challenge response by perform- 
ing said KCF on said second challenge and type 
data using said secondary key, said type data indi- 
cating an update SSD protocol is being performed 
by said first and second parties. 

18. The method of claim 15, wherein said step (e) gen- 
erates said second challenge response by perform- 
ing said KCF on said second challenge, an identifier 
for said first party and type data using said second- 
ary key, said type data indicating an update SSD 
protocol is being performed by said first and second 
parties. 

19. The method of claim 11 , wherein 

said first party is said network and said second 
party is a mobile. 

20. The method of claim. 1 9, wherein 
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said step (b) receives said second challenge, a 
count value and said first challenge response 
from said mobile, said first challenge response 30 
being a result of performing said KCF on said 
first challenge, said second challenge, and said 
count value using said secondary key; and 

said step (e) verifies said mobile based on said 
first challenge, said second challenge, said first 
challenge response, and said count value. 



35 



21. The method of claim 11, wherein said secondary 
key is derived from a root key. 

22. The method of claim 11, wherein said secondary 
key is not a secret shared data. 
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